A computer or data processing machine is a machine that is able to execute a series of instructions or steps so as to perform some predetermined functions. This series of instructions or steps is usually called a program or application.
As applications of increasing complexity are developed, it has become the practice to combine together programs to produce the required functionality. FIG. 1 of the accompanying drawings illustrates a simple example where two programs 1 and 2 interact, this interaction being represented schematically by the complementary shapes of the programs 1 and 2. Program 2 is typically a library program comprising a number of routines for executing standard functions, whilst program 1 may be a user application making use of at least some of the library routines.
By way of example, program 2 may be a print library "PR.a" in binary form including, in particular, a routine PRINT. As illustrated in FIG. 2, binary print library "PR.a" is derived from a source code version "print.c" of the print library by compilation (step 10). In accordance with standard practice, "print.c" will generally include a reference to a header file "print.h" containing the function prototypes for the routines contained in the print library; in compiling "print.c", the compiler will make use of the information in the header file.
The print library will frequently only be distributed in its binary form "PR.a" together with the associated header file "print.h".
To use the PRINT routine in the library, the source code of a user application 1, such as "main.c" includes a reference to the library header file "print.h". On the program "main.c" being compiled (step 11), the information in the header file is used by the compiler in producing the binary file "object" of the user application. Of course, before the user application can be run, it must be linked (step 12) to the binary form of the print library to produce an executable program "execut". Now when the program "execut" is run, a call for the routine PRINT results in the corresponding code in the print library being executed.
A problem that frequently arises with complex applications is to understand the interaction between the different constituent programs, so as to check the correct operation of the computer and of each of the programs when they are run by the computer. This problem is notably encountered when applications are being debugged or tested and is made more difficult by the fact that the source code of library programs is frequently not available. Another problem is to trace or determine particular parameters of the computer running the application, at the time functions calls are made between different parts of the application, that is to determine the conditions prevailing in a computer running the applications. Such parameters could include the free memory area, or the number and type of available resources, or other technical features of the computer.
A prior solution to at least some of these problems is disclosed in IBM Technical Disclosure Bulletin, vol 37, no 03, March 1994, New York US, pages 373-375, "Execution Trace Analysis of OS/2 2.". However, in the solution there proposed, the required parameters to be monitored must be pre-specified. It is an object of the present invention to provide an improved monitoring method.